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Sir: 



Appellant filed a Brief on Appeal to the Board of Patent Appeals and 
Interferences for the above-captioned application on August 18, 2010, appealing the 
decision of the Examiner in the Final Office Action mailed January 25, 2010. The 
Examiner's Answer was mailed November 12, 2010. In reply to the Examiner's 
Answer, Appellant submits this Reply Brief under 37 C.F.R. § 41.41. 

Appellant maintains the position that the combination of RlPscrip, Microsoft, 
Zellweger, and Kleinerman does not teach or suggest each and every feature of 
independent claims 114, 133, 153, and 171. In particular, Appellant maintains that the 
combination of RlPscrip, Microsoft, Zellweger, and Kleinerman does not teach or 
suggest at least "wherein the third instructions receive via the API a response to the 
functional request from the online service in the background, thereby permitting the 
graphical user interface to continue operation" as recited in claims 1 14, 133, 153, and 
171. 



-2- Richard R. REISMAN 

Appl. No. 09/553,337 

In the Examiner's Answer, the Examiner continues to implicitly acknowledge that 

RIPscrip, Microsoft, and Zellweger do not teach or suggest the above noted feature 

recited in claims 1 14, 133, 153, and 171, and instead relies on Kleinerman to cure this 

deficiency with respect to the other references. In addition, and in response to the 

arguments presented in Appellant's Brief on Appeal filed August 18, 2010, the Examiner 

contends that: (1) Appellant's argument that Kleinerman teaches away fails; (2) 

Appellant did not adequately traverse the Official Notice taken by the Examiner; and (3) 

the above noted feature recited in claims 1 14, 133, 153, and 171 is equivalent to a 

multitasking operating system, which was well known prior to the priority date of the 

present application. (See Examiner's Answer, pp. 15-22.) Appellant respectfully 

disagrees with each of these contentions and addresses each in turn below. 

/. The Examiner Incorrectly Contends That Appellant Argues That Kleinerman 
Teaches Away From the Feature Recited In Claims 114, 133, 153, and 171 

On page 18 of the Examiner's Answer, the Examiner alleges that Appellant 

argues that Kleinerman teaches away from the feature "wherein the third instructions 

receive via the API a response to the functional request from the online service in the 

background, thereby permitting the graphical user interface to continue operation" as 

recited in claims 114, 133, 153, and 171. However, Appellant makes no such argument 

either literally or "in effect." In fact, Appellant explicitly stated the following in the 

Brief on Appeal: 

On page 10 of the final Office Action mailed January 25, 2010, the 
Examiner contends that Appellant previously argued "that 
Kleinerman in effect teaches away from API [sic] performing 'in 
the background.'" Appellant respectfully submits that no such 
argument was made. Rather, Appellant previously argued in the 
reply dated May 22, 2009 that Kleinerman failed to teach or 
suggest an API that is configured to receive "a response to [a] 
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functional request from [an] online service in the background" as 
recited in independent claims 1 14, 133, 153, and 171. 

(Brief on Appeal, p. 12.) 

Thus, any argument presented by the Examiner that Kleinerman does not teach 

away from the above noted feature recited in claims 114, 133, 153, and 171 is 

immaterial. What is relevant is whether Kleinerman teaches or suggests (which it does 

not) "wherein the third instructions receive via the API a response to the functional 

request from the online service in the background, thereby permitting the graphical user 

interface to continue operation" as recited in claims 114, 133, 153, and 171. 

//. The Examiner Incorrectly Contends That Appellant Did Not Adequately 
Traverse the Taking Of Official Notice 

To traverse Official Notice, an Applicant must specifically point out the supposed 
error(s) in the Examiner's action, which would include stating why the noticed fact is not 
considered to be common knowledge or well-known in the art. MPEP § 2144.03(C). 
Contrary to the Examiner's assertion on page 20 of the Examiner's Answer, Appellant did 
just this in the Brief on Appeal. (See Brief on Appeal, pp. 13-14.) 

In particular, the Examiner alleged the fact, without any documentary evidence, 
that an API configured to receive "a response to [a] functional request from [an] online 
service in the background," as recited in claims 114, 133, 153, and 171, was common 
knowledge in the art. (final Office Action mailed January 25, 2010, p. 1 1 .) In response, 
on pages 13-14 of the Brief on Appeal, Appellant pointed out that this alleged fact is not 
"capable of instant and unquestionable demonstration as being well known," as expressly 
required by section 2144.03(A) of the MPEP to take Official Notice. Rather, this 
alleged fact relates to "the state of the art" at the time of the earliest effective filing date 
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of the instant application (which was fifteen years ago when the Internet was still in its 
infancy) and is "subject to the possibility of rational disagreement among reasonable 
men." See In re Eynde, 480 F.2d at 1370, 178 USPQ at 474. 

Accordingly, because Appellant specifically pointed out the supposed error(s) in 
the Examiner's action, the Official Notice of the alleged fact was properly traversed. 
MPEP § 2144.03(C). 

III. The Examiner Incorrectly Contends That a Multitasking Operating System 
Teaches the Feature Recited In Claims 114, 133, 153, and 1 71 

The Examiner incorrectly contends that the AmigaOS and Microsoft Windows 

multitasking operating systems (as referenced in the Examiner's Answer on pages 20-22) 

teach the feature "wherein the third instructions receive via the API a response to the 

functional request from the online service in the background, thereby permitting the 

graphical user interface to continue operation" as recited in claims 1 14, 133, 153, and 

171. However, these operating systems at most disclose placing one task in the 

background while another task is actively executing. This functionality does not come 

close to the non-obvious and advantageous feature of claims 114, 133, and 153, and 171 

noted above. 

For example, unlike the feature recited in claims 1 14, 133, and 153, and 171, 
these operating systems cited by the Examiner do not teach or suggest the specifics of 
receiving a response to a functional request from an online service in the background, let 
alone receiving such a response via an API from an online service in the background. 
The cited to multitasking operating systems may allow one task to be placed in the 
background while another task is currently being executed; however, these operating 
systems do not teach or suggest allowing a user interface to continue operation in 
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between the time a functional request is sent to an online service and a response to the 
functional request is received from the online service like the feature recited in claims 
1 14, 133, and 153, and 171. This may provide for a more dynamic application, 
eliminating the need for start and stop interactions between a client application that uses 
information from remote sources and an online service. In addition, because the 
response is received from the online service in the background, any interaction with the 
online service can be transparent to a user. These features are not taught or suggested by 
the operating systems cited to by the Examiner. 

Thus, like the combination of REPscrip, Microsoft, Zellweger, and Kleinerman, 
the AmigaOS and Microsoft Windows operating systems fail to teach or suggest 
"wherein the third instructions receive via the API a response to the functional request 
from the online service in the background, thereby permitting the graphical user interface 
to continue operation" as recited in claims 114, 133, 153, and 171. 

In light of the arguments above, as well as those set forth in Appellant's Brief on 
Appeal filed August 18, 2010. Appellant respectfully submits that the final rejection of 
claims 114-122, 124-126, 128-141, 143-145, 147-155, 157-161, 163-173, 175-179, and 
181-202 is improper and should be reversed. 
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